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The possibility of corruption of critical information required in the operation of a host computer (10) is reduced by storing 
the critical information in a device (22) ; communicating authorization information between the device (22) and the host computer 
(10); and causing the device (22), in response to the authorization information, to enable the host computer (10) to read the criti- 
cal information stored in the device (22). The device (22) includes a housing, a memory (36) within the housing containing infor- 
mation needed for startup of the host computer (10), and communication channel for allowing the memory (36) to be accessed ex- 
ternally of the housing. The device (22) is initialized by storing the critical information in memory (36) on the device (22), storing 
authorization information in memory (36) on the device (22), and configuring a microprocessor (34) in the device (22) to release 
the critical information to the host computer (10) only after completing an authorization routine based on the authorization infor- 
mation. 
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SYSTEM FOR PROTECTING COMPUTERS VIA 
INTELLIGENT TOKENS OR SMART CARDS 
Background of the Invention 
5 This invention relates to reducing the possibility 

of corruption of critical information required in the 
operation of a computer system. In particular, the 
invention is aimed at preventing boot-sector computer 
viruses and protecting critical executable code from 

10 virus infection. 

The process of starting up a computer, i.e., 
booting or boot-strapping a computer is well known, but 
we describe aspects of it here for the sake of clarity 
and in order to define certain terms and outline certain 

15 problems which are solved by this invention. 

Fig. l depicts a typical computer system 10 with 
central processing unit (CPU) 12 connected to memory 14. 
Display 18, keyboard 16, hard disk drive 17, and floppy 
disk drive 19 are connected to computer system 10. 

20 A typical computer system such as shown in Fig. 1 

uses a program or set of programs called an operating 
system (OS) as an interface between the underlying 
hardware of the system and its users. A typical OS, 
e.g. , MS-DOS Version 5.0, is usually divided into at 

25 least two parts or levels. The first level of the OS, 
often referred to as the kernel of the OS, provides a 
number of low-level functions called OS primitives which 
interact directly with the hardware. These low-level 
primitives include, for example, functions that provide 

30 the basic interface programs to the computer system's 
keyboard 16, disk drives 17, 19, display 18, and other 
attached hardware devices. The OS primitives also 
include programs that control the execution of other 
programs, e.g., programs that load and initiate the 

35 execution of other programs. Thus, for example, if a 
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user wishes to run a word-processing program or a game 
program, it is the primitives in the OS kernel which load 
the user's program from a disk in one of the attached 
disk drives 17, 19 into the computer system's memory 14 
5 and begins executing it on CPU 12. 

The second level of the OS typically consists of a 
number of executable programs that perform higher- level 
(at least from a user's perspective) system related 
tasks f e.g., creating, modifying, and deleting computer 

10 files, reading and writing computer disks or tapes, 

displaying data on a screen, printing data, etc. These 
second-level OS programs make use of the kernel's 
primitives to perform their tasks. A user is usually 
unaware of the difference between the kernel functions 

15 and those which are performed by other programs. 

A third level of the OS, if it exists, might 
relate to the presentation of the OS interface to the 
user. Each level makes use of the functionality provided 
by the previous levels, and, in a well designed system, 

20 each level uses only the functionality provided by the 
immediate previous level, e.g., in a four level OS, level 
3 only uses level 2 functions, level 2 only uses level 1 
functions, level 1 only uses level 0 functions, and level 
0 is the only level that uses direct hardware 

2 5 instructions . 

Fig. 2 depicts an idealized view of a four level 
OS, with a level for hardware (level 0) 2, the kernel 
(level 1) 4, the file system (level 2) 6, and the user 
interface (level 3) 8. 

30 An OS provides computer users with access and 

interface to a computer system. Operating systems are 
constantly evolving and developing to add improved 
features and interfaces. Furthermore, since an OS is 
merely a collection of programs (as described above) , the 

35 same computer system, e.g. that shown in Fig. 1, can have 
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a different OS running on it at different times. For 
example, the same IBM personal computer can run a 
command-line based 0S f e.g., MS-DOS V5.0, or a graphical, 
icon based OS, e.g., MS-Windows 3.0. 
5 In order to deal with the evolution of operating 

systems (as well as to deal possible errors in existing 
operating systems) computer system manufacturers have 
developed a multi-stage startup process, or boot process, 
for computers. Rather than build a version of the OS 
10 into the system, the multi-stage boot process works as 
follows : 

A boot program is built into the computer system 
and resides permanently in read-only memory (ROM) or 
programmable read-only memory (PROM) (which is part of 

15 memory 14) on the system. Referring to Fig. 4, a 

computer system's memory 14 can consist of a combination 
of Random Access Memory (RAM) 24 and ROM 26. The ROM (or 
PROM) containing the boot program is called the boot ROM 
28 (or boot PROM ) . A boot program is a series of very 

20 basic instructions to the computer's hardware that are 
initiated whenever the computer system is powered up (or, 
on some systems, whenever a certain sequence of keys or 
buttons are pressed) . The specific function of the boot 
program is to locate the OS, load it into the computer's 

25 memory, and begin its execution. These boot programs 
include the most primitive instructions for the machine 
to access any devices attached to it, e.g., the keyboard, 
the display, disk drives, a CD-ROM drive, a mouse, etc. 

To simplify boot programs and to make their task 

30 of locating the OS easy, most computer system 

manufacturers adopt conventions as to where the boot 
program is to find the OS. Two of these conventions are: 
the OS is located in a specific location on a disk, or 
the OS is located in a specific named file on a disk. 

35 The latter approach is adopted by the Apple Macintosh™ 
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computer where the boot program looks for a file named 
"System" (which contains, e.g., Apple's icon-based 
graphical OS) on disks attached to the computer. The 
former approach, i.e., looking for the OS in a particular 
5 location, e.g., on a disk, is the one currently used by 
most I.B.M. personal computers (and clones of those 
systems) . In these systems the boot program looks, in a 
predetermined order, for disks in the various disk drives 
connected to the system (many computer systems today have 
10 a number of disk drives, e.g., a floppy-disk drive, a CD- 
ROM, and a hard-disk drive).' Once the boot program finds 
a disk in a disk drive, it looks at a particular location 
on that disk for the OS. That location is called the 
frQot sector of the disk. 
15 Referring to Fig. 3, a physical disk 9 is divided 

into tracks which are divided up into sectors 11 (these 
may actually be physically marked, e.g., by holes in the 
disk, in which case they are called hard-sectored, but 
more typically the layout of a disk is a logical, i.e. 
20 abstract layout) . The boot sector is always in a 
specific sector on a disk, so the boot program knows 
where to look for it. Some systems will not allow 
anything except an OS to be written to the boot sector, 
others assume that the contents of the boot sector could 
25 be anything and therefore adopt conventions, e.g., a 
signature in the first part of the boot sector, that 
enables the boot program to determine whether or not it 
has found a boot sector with an OS. If not it can either 
give up and warn the user or it can try the next disk 
30 drive in its predetermined search sequence. 

Once the boot program has determined that it has 
found a boot sector with an OS (or part of an OS) , it 
loads (reads) into memory 14 the contents of the boot 
sector and then begins the execution of the OS it has 
35 just loaded. When the OS begins execution it may try to 
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locate more files, e.g., the second level files described 
above, before it allows the user access to the system. 
For example, in a DOS-based system, the program in the 
boot sector, when executed, will locate, load into 
5 memory, and execute the files, 10. SYS, MSDOS.SYS, 

C0MMAND.COM, CONFIG.SYS, and AUTOEXEC.BAT. (Similarly, 
in a multi-level system, each level loads the next one, 
e.g., the Hewlett-Packard Unix™ -like System HPUX has at 
least 4 levels which get loaded before the user is 

10 presented with an interface to the computer system.) 

The process of booting a computer system is 
sometimes called the boot sequence . Sometimes the boot 
sequence is used to refer only to the process executed by 
the first boot program. 

15 Computer viruses aimed at personal computers (PCs) 

have proliferated in recent years. One class of PC 
viruses is known as boot infectors . These viruses infect 
the boot-sectors of floppy or hard disks in such a way 
that when the boot sequence of instructions is initiated, 

20 the virus code is loaded into the computer's memory. 

Because execution of the boot sequence precedes execution 
of all application programs on the computer, antiviral 
software is generally unable to prevent execution of a 
boot-sector virus. 

25 Recall, from the discussion above, that the boot 

program loads into memory the code it finds in the boot 
sector as long as that code appears to the boot program 
to be valid. 

In addition to the boot infector class of viruses, 
30 there is another class of viruses called file infectors 
which infect executable and related (e.g., overlay) 
files. Each class of virus requires a different level or 
mode of protection. 

File infector viruses typically infect executable 
35 code (programs) by placing a copy of themselves within 
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the program; when the infected program is executed so is 
the viral code. In general, this type of virus code 
spreads by searching the computer's file system for other 
executables to infect, thereby spreading throughout the 

computer system. 

One way that boot-sector viruses are spread xs by 
copying themselves onto the boot-sectors of all disks 
used with the infected computers. When those xnfected 
disks are subsequently used with other computers, as xs 
often the case with floppy disks, they transfer the 
infection to the boot-sectors of the disks attached to 
other machines. Some boot-sector viruses are also fxle 
infectors. These viruses copy themselves to any 
executable file they can find. In that way, when the 
infected file is executed it will infect the boot sectors 
of all the disks on the computer system on which xt xs 

running. _ 

Recall, from the discussion above, that an OS may 

consist of a number of levels, some of which are loaded 
20 from a boot sector, and others of which may be loaded 
into the system from other files on a dxsk. It xs 
possible to infect an OS with a virus by either infectxng 
that part of it the resides in the boot sectbr (wxth a 
boot-sector virus) or by infecting the part of it that xs 
25 loaded from other files (with a f ile-inf ector virus) , or 
both. Thus, in order to maintain the integrxty of a 
computer operating system and prevent viruses from 
infecting it, it is useful and necessary to prevent both 
boot-sector and f ile-inf ector viruses. 
30 Work to develop virus protection for computers has 

often been aimed at PCs and workstations, which are 
extremely vulnerable to virus infection. The many 
commercial packages available to combat and/or recover 
from viral infection attest to the level of effort xn 
35 this area. 
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Unfortunately, computer virus authors produce new 
versions and strains of virus code far more rapidly than 
programs can be developed to identify and combat them. 
Since viruses are typically recognized by a "signature", 
5 i.e., a unique sequence of instructions, new viral code 
may at times be difficult to identify. Existing 
signature-based virus detection and eradication programs 
require knowledge of the signature of a virus in order to 
detect that virus. 

10 Current systems employ different strategies to defend 
against each type of virus. In one of these strategies 
to protect against boot infectors, first a clean 
(uninfected) copy of the boot-sector is made and kept on 
a backup device, e.g., a separate backup disk. 

15 Subsequent attempts to write to the boot-sector are 

detected by the anti-viral software in conjunction with 
the OS and the user is warned of potential problems of 
viral infection. Since reading from and writing to a 
disk is a function performed by the OS kernel, it knows 

20 when a disk is written to and which part of the disk is 
being written. Anti-virus software can be used to 
monitor every disk write to catch those that attempt to 
modify the boot sector. (Similarly, in systems which 
keep the OS in a particular named file, every attempt to 

25 modify that file can be caught). At this point, if the 
boot-sector has been corrupted the user can replace it 
with a clean copy from the backup disk. 

To inhibit file infectors an integrity check, 
e.g., a checksum is calculated and maintained of all 

30 executables on the system, so that any subsequent 

modification may be detected. A checksum is typically an 
integral value associated with a file that is some 
function of the contents of the file. In the most common 
and simple case the checksum of a file is the sum of the 

35 integer values obtained by considering each byte of data 
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in the file as an integer value. Other more complicated 
schemes of determining a checksum are possible, e.g., the 
sum of the bytes in the file added to the size of the 
file in bytes. Whatever the scheme used, a change in the 
5 file will almost always cause a corresponding change in 
the checksum value for that file, thereby giving an 
indication that the file has been modified. If a file is 
found with a changed checksum, it is assumed to be 
infected. It can be removed from the computer system and 
10 a clean copy can restored from backup. 

Many viruses use the low-level primitive functions 
of the OS, e.g., disk reads and writes, to access the 
hardware. As mentioned above, these viruses can often be 
caught by anti-viral software that monitors all use of 
15 the OS's primitives. To further complicate matters 

however, some viruses issue machine instructions directly 
to the hardware, thus avoiding the use of OS primitive 
functions. Viruses which issue instructions directly to 
the hardware can bypass software defenses because there 
20 is no way that their activities can be monitored. 

Further, new self-encrypting (stealth) viruses may be 
extremely difficult to detect, and thus may be overlooked 
by signature recognition programs. 

One approach to the boot integrity problem is to 
25 place the entire operating system in read-only memory 
(ROM) 26 of the computer 10. However, this approach has 
disadvantages in that it prevents modifications to boot 
information, but at the cost of updatability. Any 
upgrades to the OS require physical access to the 
hardware and replacement of the ROM chips. It is also 
the case that as operating systems become more and more 
sophisticated, they become larger and larger. Their 
placement in ROM would require larger and larger ROMs. 
If user authentication is added to the boot program, 
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passwords may be difficult to change and operate on a per 
machine rather than a per user basis. 

Some Operating Systems have so-called login 
programs which require users to enter a password in order 
5 to use the system. These login programs, whether stand- 
alone or integrated with an antiviral program, suffer 
from the same timing issues as previously mentioned. 
Also since most PCs provide a means of booting from 
alternate devices, e.g., a floppy disc drive, login 
10 programs can often be trivially defeated. 

sinrnnary of the invention 
in general, in one aspect, the invention features 
reducing the possibility of corruption of critical 
information required in the operation of a computer, by 
15 storing the critical information in a device; 

communicating authorization information between the 
device and the computer; and causing the device, in 
" response to the authorization information, to enable the 
computer to read the critical information stored in the 
20 device. 

Embodiments of the invention include the following 
features. The authorization information may be a 
password entered by a user and verified by the device (by 
comparison with a pre-stored password for the user) ; or 
25 biometric information (e.g. a fingerprint) about a user. 
The device may be a pocket-sized card containing the 
microprocessor and the memory (e.g., a smartcard) . The 
critical information may include boot-sector information 
used in starting the computer; or executable code; or 
30 system data or user data; or file integrity information. 
The computer may boot itself from the critical 
information read from the device by executing modified 
boot code (stored as a BIOS extension) in place of normal 
boot code. 
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The device may pass to the computer secret 
information shared with the computer (e.g., a host access 
code) ; the computer validates the shared secret 
information. The authorization information may be file 
5 signatures for executable code; or a user's cryptographs 

key. . . 

A communication link between the device and the 

computer carries the authorization information and the 
critical information. 
10 in general, in another aspect, the invention 

features initializing a device for use in reducing the 
possibility of corruption of critical information 
required in the operation of a computer, by storing the 
critical information in memory on the device, storing 
15 authorization information in memory on the device, and 
configuring a microprocessor in the device to release the 
critical information to the computer only after 
" completing an authorization routine based on the 
authorization information. 
20 in general, in another aspect, the invention 

features a portable intelligent token for use in 
effecting a secure startup of a host computer. The token 
includes a housing, a memory within the housing 
containing information needed for startup of the host 
25 computer, and a communication channel for allowing the 
memory to be accessed externally of the housing. 

in embodiments of the invention, the memory also 
contains a password for authorization, and a processor 
for comparing the stored password with externally 
30 supplied passwords. The memory may store information 
with respect to multiple host computers. 

Among the advantages of the invention are the 

following. 

The invention provides extremely powerful security 
35 at relatively low cost, measured both in terms of 
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purchase price and setup time. The additional hardware 
required is nominal, initial setup is one-time only, and 
upgrades require no hardware access— provided the user 
has the proper authentication. The invention obviates 
5 the need to defend against boot infectors and greatly 
reduces the risk to selected executables. The invention 
eliminates the PC's vulnerability to boot infectors, 
ensures the integrity of selected data, and guarantees 
the reliability of executables uploaded from the 

10 smartcard. Due to the authentication which occurs in the 
boot sequence, the possibility of sabotage or 
unauthorized use of the PC is restricted to those users 
who possess both a properly configured smartcard and the 
ability to activate it. 

15 Other advantages and features will become apparent 

from the following description and from the claims. 

Description 

Fig. 1 is a diagram of a typical computer system 

using the invention; 
20 Fig. 2 depicts the levels of an operating system; 

Fig. 3 shows the layout of a computer disk; 
Fig. 4 is a view of the memory of the computer 

system shown in Fig. 1; 

Figs. 5-6 show, schematically, a smartcard and its 

25 memory; 

Figs. 7-10 are flow diagrams of boot processes. 
The invention makes use of so-called intelligent 
tokens to store a protected copy of the file that is 
usually stored in a disk boot sector, along with other 
30 file integrity data. 

Intelligent tokens are a class of small (pocket- 
sized) computer devices which consist of an integrated 
circuit (IC) mounted on a transport medium such as 
plastic. They may also include downsized peripherals 
35 necessary for the token's application. Examples of such 
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peripherals are Keypads, displays, and biometric devices 
^eg thumbprint scanners,. The portability of these 
iokens lends itself tc security-sensitive applicat^s. 
& subclass of intelligent tokens are IC cards, 
5 also known as smartcards. The physical characteristics 
of smartcards are specified by The International 
Standards organization (ISO, (described in International 
Standard 7816-1, Identification Cards - Integrated 
Circuit(s) with contacts - Physical Characterises, 
10 international Standards Organisation, 1987) In brief, 
the standard defines a smartcard as a ~- 
piece of flexible plastic with an IC embedded in the 
upper left hand side. communication with the smartcard 
is accomplished through contacts which overlay the IC 
15 (described in International Standard 7816-2. 

Identification Cards - Integrated Circuity, With 
contacts - Dimensions and Location cf the Contacts 
mternational Standards organization, 1988,. Further 
ISO also defines multiple communications protocols for 
20 issuing commands to a smartcard (described in 

nternltional Standard 7818-3, Identification cards - 
^tegrated Circuits, Kith Contacts - Electronic Signals 
and Transmission Protocols, International Standards 
organization, 1989,. While all references to smartcards 
25 here refer to ISO standard smartcards, the concepts and 
.^cations are valid for intelligent tokens in general. 

The capability of a smartcard is defined by its 
IC is the name implies, an integrated circuit consists 
of multiple components combined within a single chip . 
30 some possible components are a microprocessor non-static 
random access memory (P*H) , read only memory (ROM, , 
electrically programmable read only memory (EPROH) , 
nonvTlacile mLory (memory which retains its state when 
current is removed) such as electrically erasable 
35 programmable read only memory (EEPROM) , and special 
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purpose coprocessor ( s) . The chip designer selects the 
components as needed and designs the chip mask. The chip 
mask is burned onto the substrate material, filled with a 
conductive material, and sealed with contacts protruding. 
5 Fig. 5 depicts a typical smartcard 22 with IC 32 

which contains a CPU 34 and memory 36. Memory 36 is made 
up of a ROM 38 and an EEPROM 40. 

The current substrate of choice is silicon. 
Unfortunately silicon, like glass, is not particularly 

10 flexible; thus to avoid breakage when the smartcard is 
bent, the IC is limited to only a few millimeters on a 
side. The size of the chip correspondingly limits the 
memory and processing resources which may be placed on 
it. For example, EEPROM occupies twice the space of ROM 

15 while RAM requires twice the space of EEPROM. Another 
factor is the mortality of the EEPROM used for data 
storage, which is generally rated for 10,000 write cycles 
and deemed unreliable after 100,000 write cycles. 

Several chip vendors (currently including Intel, 

20 Motorola, SGS Thompson, and Hitachi) provide ICs for use 
in smartcards. In general, these vendors have adapted 
. eight-bit micro-controllers, with clock rates of 

approximately 4 megahertz (Mhz) for use in smartcards. 
However, higher performance chips are under development. 

25 Hitachi's H8/310 is representative of the capabilities of 
today's smartcard chips. It provides 256 bytes of RAM, 
10 kilobytes (K) of ROM, and 8K of EEPROM. The 
successor, the H8/510, not yet released, claims a 16-bit 
10 Mhz processor, and twice the memory of the H8/310. It 

30 is assumed that other vendors have similar chips in 
various stages of development. 

Due to these and other limits imposed by current 
technology, tokens are often built to application- 
specific standards. For example, while there is 

35 increased security in incorporating peripherals with the 
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token, the resulting expense and dimensions of self- 
contained tokens is often prohibitive. Because of the 
downsizing required for token- based peripherals, there 
are also usability issues involved. From a practical 
5 perspective, peripherals may be externally provided as 
long as there is reasonable assurance of the integrity of 
the hardware and software interface provided. The 
thickness and bend requirements for smart cards do not 
currently allow for the incorporation of such 

10 peripherals, nor is it currently feasible to provide a 
constant power supply. Thus, today's smartcards must 
depend upon externally provided peripherals to supply 
user input as well as time and date information, and a 
means to display output. Even if such devices existed 

15 for smartcards, it is likely that cost would prohibit 
their use. For most applications it is more cost 
effective to provide a single set of high cost 
input /output (I/O) devices for multiple cards (costing 
$15-$20 each) than to increase smartcard cost by orders 

20 of magnitude. This approach has the added benefit of 
encouraging the proliferation of cardholders. 

Smartcards are more than adequate for a variety of 
applications in the field of computer security (and a 
number of applications outside the field) . The National 

25 Institute of Standards and Technology (NIST) has 

developed the Advanced Secure Access Control System 
(ASACS) which provides both symmetric (secret key) and 
asymmetric (public key) cryptographic algorithms on a 
smartcard (described in An Overview Of The Advanced 

30 Smartcard Access Control System, J. Dray and D. Balenson, 
Computer Security Division/ Computer Systems Laboratory, 
National Institute of Standards and Technology, 
Gaithersburg, Maryland) . The ASACS utilizes DES (Data 
Encryption Standard) (described in Data Encryption 

35 Standard - FIPS Publication 46-1, National Institute of 
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Standards and Technology (formerly NBS) , Gaithersburg, 
Maryland) for login authentication using the 9.26 
standard authentication protocol (defined in Financial 
Institution Sign-on Authentication For Wholesale 
5 Financial Systems [DES-based user authentication 

protocols], ANSI X9.26, X9 Secretariat, American Bankers 
Association, Washington, D.C.). It further offers a 
choice of RSA (described in R. L. Rivest, A. Shamir, L. 
M. Adleman, "A Method for Obtaining Digital Signatures 

10 and Public Key Cryptosystems, " Communications of the ACM, 
pp. 120-126, Volume 21, Number 2, February 1978) or DSA 
(described in "The Digital Signature Standard Proposed by 
NIST M , Communications of the ACM, Volume 35, No. 7, July, 
1992, pp. 36-40) for digital signatures. 

15 The ASACS card provides strong security because 

all secret information is utilized solely within the 
confines of the card. It is never necessary for a secret 
or private key to be transferred from the card to a host 
computer; all cryptographic operations are performed in 

20 their entirety on the card. Although the current H8/310 
equipped card requires up to 20 seconds to perform sign 
and verify operations, a new card developed for the 
National Security Agency (NSA) is capable of performing 
the same operations in less than a second. The NSA card 

25 is equipped with an Intel 8031 processor, a Cylink CY513 
modular exponent ia tor (coprocessor) , 512 bytes of RAM and 
16 Kbytes of EEPROM. Since both the RSA and DSA 
algorithms are based on modular exponentiation, it is the 
Cylink coprocessor which accounts for the NSA card's 

30 greatly enhanced performance. 

Trusted Information Systems (TIS) , a private 
computer security company, is currently integrating 
smart cards for use with privacy enhanced computer mail in 
a product called TISPEM. A user-supplied smartcard is 

35 used to store the user's private key and in addition 
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provides service calls for digital signatures and 
encryption so that all operations involving the private 
key are performed on the card. In this way the private 
key need never leave the card. Thus, a TISPEM user can 
5 sit down at any terminal which has access to the 

application software (and a smartcard reader) and read 
encrypted mail and send signed messages without fear of 
compromising his or her private key. 

Referring to Figs. 5 and 6, in the invention, a 
10 smartcard 's memory 36 contains an propriety operating 
system and software programs to enforce access control 
(in ROM 38) together with critical information 42, 44, 46 
usually stored in the host's boot-sector, directory, and 
executables (in EEPROM 40) . The amount of memory 
15 available on the token will dictate the amount of data 
which may be stored. In addition, other sensitive or 
private information 48 may be stored to ensure its 
integrity. 

One aspect of I.B.M. personal computers and their 
20 clones is that the computer systems are not all 

identically configured. Some computer systems may have 
devices, e.g., display monitors or optical disks, that 
other systems do not have. Some of these computer 
systems have slots which can accept addin boards which 
25 can be used to enhance the system by, for example 

increasing its speed or the resolution of its display. 
In order to overcome the complications introduced by non- 
uniformity of computer platforms, a set of functions that 
provide an interface to the low-level input /output (I/O) 
30 system is provided. In the I.B.M. PC systems this system 
is called the Basic Input Output System (BIOS) and 
resides in the EPROM and is loaded by the boot program 
before it loads the program from the boot sector. 

I.B.M. PCs are expandable and can have new devices 
35 attached to them using cards inserted into slots in the 
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computer's chassis. A new device or card may need to 
extend the interface to the low-level I/O system, i.e., 
to extend the BIOS. To do this it uses a BIOS Extension . 
The system takes advantage of the following 
5 feature of the PC's boot sequence: after loading the BIOS 
but before loading the boot sector, the boot program 
examines each expansion slot in the computer, looking for 
a BIOS extension. If it finds one it hands over control 
to that extension. In a typical PC system the BIOS 

10 extension would load its functions into the system and 
then pass control back to the boot program. After 
checking all extension slots for BIOS extensions the boot 
program then begins looking in the disk drives for a disk 
with a boot sector from which to boot. 

15 Fig. 7 describes the boot sequence of a PC. When 

the boot sequence is started 50 (either by cycling the 
power of the computer or by pressing a particular 
sequence of keys on the keyboard) the boot program in ROM 
28 of the computer system loads the BIOS code 52 into 

20 memory 14. This BIOS code allows the program to interact 
with attached devices. The boot program then examines 
each slot 54 (by address) in turn to determine if it 
contains a board with a BIOS extension 56. If the boot 
program finds a slot with a BIOS extension then it loads 

25 and executes the code associated with that BIOS extension 
58. After the BIOS extension's code is executed, control 
is passed back to the boot program to examine the next 
slot address 54. When all slots have been examined the 
boot program then tries to find a boot disk , i.e., a disk 

30 with a boot sector 60. (I.B.M. PCs are configured to 
look for a boot disk starting in the floppy drives and 
then on the hard drives.) Once a boot disk is found, its 
boot sector is loaded and executed 62. 
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B gfflartcardrBased Segratiag system 
A prototype of the invention, also referred to 
herein as The Boot Integrity Token System (BITS) , has 
been developed to provide computer boot integrity and 
enforce access control for an IBM or compatible system 
(PC-BITS) , although the technology described is 
applicable to a wide variety of other computer systems 

Referring again to Fig. 1, the basic idea behxnd 
BITS is that the host computer system 10 will actually 
boot itself from a smartcard 22. Since the smartcard 22 
can be readily configured to require user authenticatxon 
prior to data access, it provides an ideal mechanism to 
secure a host computer. Thus, if critical information 
required to complete the boot sequence is retrieved from 
15 a smartcard, boot integrity may be reasonably assured. 
The security of the system assumes the physical security 
of the host either with a tamper-proof or tamper-evident 
casing, and the security of the smartcard by its desxgn 
and configuration. If an attacker can gain physxcal 
20 access to the hardware, it is impossible to guarantee 

system integrity. 

Referring to Figs. 1 and 4-6, the PC-BITS 
prototype consists of an 8-bit addin board 30, a 
smartcard drive 20 (reader/writer) which mounts xn a 
25 floppy bay of computer system 10, configuration as well 
as file signature validation software, and a supply of 
smartcards. The board 30 contains a special boot PROM 
which is loaded with a program which interfaces to the 
smartcard reader. Further, the board is configurable to 
30 set an identifier for the host. 

installation and configuration of the host can be 
accomplished in minutes. The process involves insertion 
of the addin board and the equivalent of the installation 
of a floppy drive. Once installed, the computer will not 
35 complete the boot sequence without a valid user 
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authentication to a properly configured smartcard. The 
reason for this is that the addin board 30 is a BIOS 
Extension board. Recall from the discussion above, with 
reference to Fig. 7, that the boot program loads and 
5 executes any and all BIOS extensions 58 before it looks 
for a boot disk 60. The addin board 30 takes control 
from the boot program when its BIOS extension is loaded, 
but it does not return control back to the boot program. 
Thus, the modified boot process is like that depicted in 

10 Fig. 8, where the process of looking for and loading a 
boot sector does not take place under control of the boot 
program, but under the control of the modified boot 
program on the BIOS Extension card. 

During system startup, two authentications must be 

15 successfully performed to complete the boot sequence. 

First, the user enters a password which is checked by the 
smartcard to confirm that the user is authorized to use 
that card. If successful, the smartcard allows the PC to 
read the boot-sector and other information from the 

20 smart-card memory. To authenticate the smartcard to the 
host, the card must also make available a secret shared 
with the host, in this case the configurable host 
identifier. Table 1 illustrates these transactions. If 
both the user and card authentication are successful, the 

25 boot sequence completes, and control is given to the PC 
operating system — some or all of which has been 
retrieved from the smartcard. The user may then proceed 
to utilize the PC in the usual fashion, uploading 
additional information (i.e., applications or application 

30 integrity information) from the smartcard as needed. 
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Step 


Action 


Implementation | 


0 


Insert card and power up 
the host 


Apply power and reset I 
card | 


1 


Authenticate user and 
present data to the 
smartcard 


Present user password to I 
the smartcard 


2 


Authenticate the card to 
the host 


Host reads shared secret 
from the smartcard 


3 


Upload boot information 


Host reads boot-sector 
from the smartcard 


4 


Integrity check host- 
resident boot 
files and complete boot 
sequence if successful 


Host computes file- 
checksum which the 
smartcard encrypts to 
form a signature; this 
value is compared with 
the signature stored on 
the card 



Table 1: PC-BITS System Startup 

The card is expected to contain critical data such 
as digital file signatures for system executables and the 

10 user's cryptographic keys. Comparing executable file 
signatures with those stored on the smartcard provides a 
virus detection mechanism which is difficult to defeat. 
This approach is consistent with a recent trend to 
validate file integrity rather than solely scan for known 

15 virus signatures. 

Refer now to Figs. 9-10, which show the control 
flow of the modified boot sequence from the point of view 
of the computer system and the smartcard respectively. 
The flow diagram in Fig. 9 shows the control flow of the 

20 modified boot program loaded from the BIOS Extension 
addin card in step 58 (Fig. 8) of the original boot 
sequence. Fig. 10 shows the processing that occurs 
(during the boot sequence) on the CPU 34 of the smartcard 
22 while it is in the smartcard reader 20. 

25 The modified boot program (the BIOS extension) 

prompts the user for a password 60 on display 18. The 
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password is read 62 from keyboard 16 and sent to the 
smartcard 22 . At the same time, the smartcard is waiting 
for a password 92. When the smartcard 22 gets a password 
94 from the computer system 10 it validates the password 
5 96 using whatever builtin validation scheme comes with 
the smartcard. If the password is invalid then the 
smartcard 22 returns a "NACK" signal 100 to the computer 
system 10, disallows reading of its data 102 and 
continues to wait for another password 92. (In some 

10 systems a count is kept of the number of times an invalid 
password is entered, with only a limited number of failed 
attempts allowed before the system shuts down and 
requires operator or administrator intervention.) If the 
password is valid then the smartcard 22 returns an "ACK" 

15 signal 98 to the computer system 10 and allows reading of 
the data in its memory and files 104. 

The computer system 10 waits for the response 66 
from the smartcard 22 and then bases its processing on 
the returned result 68. If the password was invalid 

20 (i.e., the smartcard returned an "NACK" signal) then the 
user is once again prompted for a password 60 (recall 
again the discussion above about limiting the number of 
attempts.) If the password is valid the user has been 
authenticated to the smartcard and now the computer 

25 system attempts to authenticate the card for the system. 
It does this (in step 70) by reading a host access code 
46 from EEPROM 40 of the smartcard 22. (The host access 
code is one of the items of data put on the smartcard by 
the system administrator during system configuration.) 

30 The host access code 46 from the smartcard is compared to 
the one that the system has stored about itself 72. If 
they are unequal then this smartcard 22 is not allowed 
for this host computer system 10 and the boot process is 
terminated 74. (Note that this termination ends the 

35 entire boot process - the boot program does not then try 
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to boot from a disk,. If the check at step 72 finds the 
iLL to be «jual then the card is authenticated to the 
^1 tteToot sector 42 from EEPROM 40 of smartcard 
"fis read (step 76, into memory 1. of computer system 



10. 



aecall that, because of the limited size of the 
B emory on smartcards today, it is not yet possible to 
stomal! the information and files for an OS the size 
o£ e g HS-DOS on a smartcard. Therefore the other 
of, e.g. ,»» ^ storage 

L0 files will have to be read from a disk or o 

device. It is, however, still possible to ensure their 
integrity by the use of integrity information, e.g., 
integrity y smartcard (by a 

checksums tor the flies, srai>= 
system administrator) . 

in step 78 the BIOS Extension program reads the 
file integrity information 44 from the EEPROtt 40 of the 
smartcard^. Then, for each file whose integrity is 
retired, e.g., IO.SYS. etc, the integrity 
tor that file is validated (step SO). If the OS flies 
20 are found to be invalid 82 then and error is reported » 
to the user on display 18. If the error is ~nsidered to 
fc. severe 88 then the boot process terminates 90 (The 
determination of what constitutes "severe" is made a 

^™*r>i«trator based on the security 
advance by the system admmxstrator na 

25 requirements of the system. In some systems no file 

changes are allowed, in others some specific files may be 

modified, but not others.) 

If the file integrity information is valid (or the 
error is not considered severe) then the boot sector that 
30 was loaded from the smartcard (in step 76) u • 

86. At this point the boot process will continue as if 
the boot sector had been loaded from a disk (as in the 

unsafe system) . 

in the BITS system, cards are configured and 
35 issued by a security officer using the software provided 
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— the current prototype is written in C to improve 
portability. 

Configuration entails the loading onto the 
smartcard of the boot sector 42 as well as digital 
5 signatures for boot files stored on the host 44. At the 
time of issue, it is necessary to specify the machine or 
set of machines 46 that the user to whom the card is 
being issued will be granted access so that a host key 
may be loaded. File integrity information and portions 

10 of the host operating system are also loaded onto the 

smartcard at this time 44. All data is read protected by 
the user's authentication (e.g., cannot be read unless 
the user password is presented correctly) , and write 
protected by the security officer authentication. This 

15 arrangement (depicted in Table 2) prevents users from 

inadvertently or deliberately corrupting critical data on 
the smartcard. 

Smartcards may be issued on a per host, per group, 

or per site basis depending on the level of security 
20 desired. Since the secret shared by the host and card is 
configurable on the host, it is possible to issue 
smartcards in a one-to-one, many-to-one, or many-to-many 
fashion. A one-to-one mapping of users to hosts 
corresponds to securing a machine for a single user. 
25 Analogously, many-to-one allows the sharing of a single 
machine, and many-to-many allows for the sharing of 
multiple machines among an explicit set of users. One- 
to-many is a possible, but usually wasteful, mapping of 
computer resources. 
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5 



Step 

0 


Action 

Security orxicei: 
creates user and 
security officer 
accounts on card 


Implementation | 

Present manufacturer password 
and load user-specified secret 
codes for accounts. 


1 


Load boot-sector onto 

3 

card 


Create a file readable under 
the user password and writable 
under the security officer 
password and write the 
partition boot record. 


2 


Compute and load 
signatures toir 
selected files 


For each file compute a hash 
which is encrypted by the card. 
This signature together with 
the file name is stored on the 
card. 


3 


Load host 

authentication 

information 


Create a file readable under 
the user password and writable 
under the security officer 
password and write a secret to 
be shared with the host. 





Table 2: BITS Smartcard configuration 



The effectiveness of BITS is limited by the 
feasibility of storing all boot-relevant information on a 
smartcard. To the extent this is possible, boot 
10 integrity will be maintained. BITS is not a virus 

checker, however, for those files whose signatures are 
stored on the smartcard, it is possible to detect the 
modification of the file on the host system. Thus the 
user may be notified that an executable is suspect before 
15 it is run. in general BITS will provide enhanced 

computer security by utilizing the secure storage and 
processing capabilities inherent to the smartcard. 

From a security perspective, the less that a user 
depends upon from a shared environment, the better. Any 
20 shared writable executable may potentially contain 

malicious code. Fortunately, advances in technology are 
likely to permit the storage of entire operating systems 
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as well as utilities on a smartcard, thus obviating the 
necessity of sharing executables altogether. 

Smartcards themselves may also be made more 
secure. Currently, authentication to the smartcard is 
5 limited to user-supplied passwords. In most systems, 
three consecutive false presentations results in the 
smartcard account being disabled. However, if biometric 
authentication (e.g., fingerprint checks or retinal 
scans) is incorporated into the card, it will be possible 
10 to achieve higher assurance in user authentication. 

To date, the size requirements of smartcards have 
imposed the greatest limitation upon their utility; the 
current state of the art is a 1.0 micron resolution in 
the burning of chip masks. However, SGS Thompson and 
15 Phillips recently announced the development of 0.7 micron 
technology as well as plans for a 0.5 micron technology. 
Regardless of these advances, the chips themselves are 
still currently limited to a few millimeters on a side 
due to the brittle nature of the silicon substrate from 
20 which they are made. A flexible substrate might allow 
chips which occupy the entire surface of the smartcard 
resulting in an exponential gain in computing resources. 

A smartcard with this capability would result in a 
truly portable (wallet-sized) personal computer which 
25 could be made widely available at relatively low cost. 
In this type of computing environment only the bulky 
human interface need be shared. A computing station 
might consist of a monitor, a keyboard, a printer, and a 
smartcard interface. The user could walk up to the 
30 computing station, supply the CPD and data storage, and 

begin work. 

The implications of this technology are 
impressive. The existence of instant PC access for 
millions regardless of location would greatly enhance the 
35 utility of computers. The ability to use the same 
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environment wherever one chooses to work would eliminate 
time spent customizing and increase productivity . The 
security provided by smartcards may also result in 
increased security for sensitive data by decreasing the 
5 likelihood of compromise or loss. 

Because of the mode in which the invention is 
used, it might be wrongly compared with a boot from 
floppy disk. While it is true that inserting a smartcard 
is similar to inserting a floppy f the interaction during 

10 the boot sequence is entirely different. The smartcard- 
based system incorporates two separate authentications, 
user to card and card to host, which are entirely absent 
from the floppy boot. Further, the integrity of the boot 
information on a floppy is protected only by an easily 

15 removed write-protect-tab; while the smartcard requires 
the authentication of the security officer in order to 
update boot information. One may also note the ease of 
carrying a smartcard as compared with a floppy disk. 

The invention has been installed and tested on a 

20 desktop computer. However, the system is easily 

generalizable to any computing environment including 
mainframe, microcomputer, workstation, or laptop. The 
intelligent token of choice for this embodiment is a 
smartcard. The reason is that ISO Standard smartcards 

25 are expected to be the most ubiquitous and consequently 
the least expensive form of intelligent token. 

Appendix A, incorporated by reference, is a source 
code listing of the BIOS Extension code loaded onto the 
memory of the addin board (as described above) written in 

30 8088 Assembly language. This code may be assembled using 
a Borland Turbo Assembler (TASM™ ) and linked using a 
Borland Turbo Linker (TUNIC* ) , and run on a AT Bus (ISA 
compatible) computer running a DOS compatible OS. 
Appendix A contains material which is subject to 

35 copyright protection. The owner has no objection to 
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facsimile reproduction by anyone of the patent document 
or the patent disclosure, as it appears in the patent and 
Trademark Office patent file or records, but otherwise 
reserves all rights whatsoever. 
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Appendix A 

copyright rights and all other rights reserved. 



5 BIOS Extension for DOS smartcard boot 

'. Version 1 

• Useful Defines 

ACK EQU 60h 

ETX EQU 03h 

10 NAK EQU OOOEOh 

COM1 CTL REG EQU 003FCh 

COMl~ DATA REG EQU 003F8h 

COMl~STAT~REG EQU 003FDh 

STACKAREA EQU 06000h 
15 SCRATCHAREA EQU 07 00 Oh 

PBRAddress EQU 07C00h 

PWDAddress EQU 0C007h 



20 



25 



30 



Cseg 



35 



Org 03h 
after extension 

Mov 
Mov 
Push 
Push 
Mov 
Mov 
Mov 
Mov 
Mov 
Push 

seg for small model 



Segment Para Public 'Code' 
Assume CStCseg 



;Code starts 



40 



increment 



stack 



Pop 
Sti 
Cld 



Call 

Pop 

Pop 
Mov 



BX,SP 
CX,SS 
BX 
CX 

AX, STACKAREA 
SS,AX 
SP,0000h 
AX, SCRATCHAREA 
ES,AX 
CS 

DS 



; signature and length 
;Save stack 



Main 

CX 

BX 

SS,CX 



;Set up new stack 

? Set scratch area 
;Data seg = Code 

;Allow breaks 
;Set direction to 



; Restore original 
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Mov 


SP,BX 








Jmp 


Intl9Hdl 


/Execute the PBR 




Abort 


Label 


Near 








DB 


OCBh 


;Far return 


5 


opcode 










■ 


Mov 


AH,4Ch 


; Return 




control to 


DOS 








• 

9 


INT 


21h 




10 


/Identify BIOS extension 








DB 


'ROM BIOS Extpnqinn 


xor uuo Diib 






DB 


'Version 1 9 




15 


;Main Program 








Main 


Proc 


Near 








Call 


InitPort 


; Initialize COM 




port 








20 




Call 


ClrScr 


; Clear screen 






Call 


DrawBox 


;Draw the frame 




for dialog 












Mov 


DX,071Ah 




25 




Mov 


SI .offset STitle 


/Display title 




Call 


StrScr 






Mov 


DX,081Eh 






subtitle 


Mov 


SI .offset SSTitle 


/Display 












Call 


StrScr 




30 




Mov 


DX.OAIDh 






card 


Mov 


SI .offset InsrtCrd 


.rroiupu user xor 












Call 


StrScr 






is inserted 


Call 


WaitCard 


;Wait until card 


35 












Call 


GetPwd 


;Get and present 




password 










Mov 


AX , SCRATCHAREA 








Mov 


ES,AX 




40 




Call 


ReadPbr 


;Read and 



install PBR from card 



Mov DX.OClAh 
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MOV 


SI, off set 


Erase 


; Erase load 




message 










Call 


StrScr 








Mov 


DX,0ClAh 




; Notify user of 


5 


file checking 




FileChk 






Mov 


SI, offset 






Call 


StrScr 








call 


Chkio 




; Check 10. SYS 




integrity 








10 


Call 


ChkMSDOS 




; Check MSDOS.SYS 




integrity 






; Check 




Call 


ChkCMD 






COMMAND.COM integrity 








Call 


ChkCFGSYS 




; Check 


15 


CONFIG.SYS integrity 










Mov 


DX,0ClAh 








Mov 


SI, offset 


Erase 


; Erase file 




check message 










Call 


StrScr 






20 


Call 


ClrScr 








Mov 


SI, off set 


PowerOff 


/Remove power 



from card 



Call CReaderCom 



;PC hangs part way through boot process 
25 technique 1 Needs fix! 

AX, AX 
DS,AX 

AX,PBRAddress 



19 handler with 

PBR 
30 ; 

where the PBR is 



35 



Xor 

Mov 

Lea 

Mov 
Push 
Pop 
Mov 
Int 



using this 

; Replace INT 
; address of 
;Jump to 



DS: [0064], AX 

CS 

AX 

DS: [0066] , AX 
19 



Main 



Ret 
Endp 



40 



Interrupt 19 (Warm Boot) Handler 

- execute PBR loaded from card, 



Intl9Hdl 



Proc 
Sti 



Far 
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DB 

EndP 
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OEAh,0Oh,7Ch,OOh,OOh ;Far JMP to 



Initialize O0K1: 9 600, N, 8,1 





InitPort 


Proc 


Near 






Push 


Aa 






Push 


DX 


10 












Mov 


AH, 00 




service 0 










nov 


at ill nnm 1 H 




parity, 8 


bit data 




15 


Mov 


DX,0000 






Int 


14h 






Pop 


DX 






Pop 


AX 


20 




Ret 






InitPort 


Endp 






;Wait for 


card to be 


inserted 


25 


WaitCard 


Proc 


Near 






Cli 






WaitLoop 


Label 


Near 






Push 


DS 


30 




Mov 


SI, offset InitRdr 




reader 










call 


CReaderCom 






Mov 


SI, off set StCrdTp 






Call 


CReaderCom 


35 




Mov 


SI, off set InitRdr 






Call 


CReaderCom 






Mov 


SI, offset PowerOn 




to card 










Call 


CReaderCom 


40 




Mov 


SI,0001h 






Mov 


BX , SCRATCHAREA 






Mov 


DS,BX 






Lodsb 








Cmp 


AL,04h 


45 


code is 4 


bytes , 








Pop 


DS 



; Interrupt 14 
;9600 baud, no 
;COMl: 



;Initizlize 

;Set card type 
; Reset card 
;Apply power 



;If return 
;Card isn't 



there ! 
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Jz 

something is there. 



- 32 
WaitLoop 



; Otherwise 



WaitCard 



Sti 
Ret 
Endp 



?Get password from user and present to card 
10 GetPwd 



Proc 
Push 
Push 
Push 
Push 
Label 
Mov 

character count 

Mov 

message 

Mov 
Call 
Mov 
Mov 

password prompt 

Call 
Mov 



15 PwdLoop 



20 



25 



Near 
AX 
CX 
DS 
DI 

Near 
CX,00h 

DX # 0AlAh 



; Initialize 

; Erase previous 



SI, offset Erase 

StrScr 

DX,0AlAh 

SI , offset PwdPrmpt ;Display 

StrScr 
DI,PWDAddress 



ReadLoop 



Label 



30 



35 



Mov 

keyboard status label 

Mov DX,0101h 
Call StrScr 
Mov AH,01h 

keyboard status 

Int I6h 
Call DispStat 

Keyboard Status 

Jz ReadLoop 

empty buffer 



Near 

SI, off set KbdStat 



; Display 



; Check 



Mov 

40 the right place 

Add 
Call 



45 from keyboard 



Mov 
Int 



DX,CX 

DX, 0A24h 
CurPos 

AH, Oh 
16h 



/Display 
;Loop on 

;Put the cursor in 



;Read character 
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<BACKSPACE> 
5 <RETURN> 

10 exceed eight 



Cmp 

Je 
Cmp 

Je 
Cmp 
Je 
Cmp 

Jge 
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AL,08h 

EraseChar 
AL, ODh 

SpaceFill 
AL,lbh 
SpaceFill 
CX,08h 

Beep 



Stosb 
presentation str 
Inc 

15 character count 

Mov 
Call 
Jmp 



EraseChar 
20 BACKSPACE 

there is? 



Label 
Cmp 
Je 



delete goto read loop 
25 Dec 
before backspace 
Dec 

count 

Call 

30 Mov 

Call 
Mov 
Call 
Jmp 



35 Beep 

continue 



Label 

Mov 
Call 
Jmp 



40 SpaceFill Label 
RETURN or ESC 
Mov 

spaces 

padloop label 
45 Cmp 
Jge 

padding, send pw 



cx 

AL, 'X' 
DisplayChar 
ReadLoop 

Near 

CX,00h 

Beep 

DI 

CX 

DisplayChar 
AL,' ' 
DisplayChar 
AL,08h 
DisplayChar 
ReadLoop 

Near 

AL,07h 
DisplayChar 
ReadLoop • 

Near 

AL,' ' 

near 

CX,08h 

Presentpw 



; Check for 

; Check for 

; check for <ESC> 
/Length cannot 

; Store as part of 
< ; Increment 



; Process a 
;Is backspace all 
;if no chars to 
; Remove character 
; Decrement char 



;Ring the bell and 



;User has pressed 
;Pad out pwd with 

; After space 
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Stosb 








xnc 


Ua 






Jmp 


paaiuup 






Presenupw jjacex 






5 


;Jmp CoaeoK 








MOV 








present code and 


nT ay 






MOV 






Mov 


AL,0Eh 




10 


Stosb 








Mov 


Aa f U U U Uriil 






Stosw 








MOV 


AX,0020h 






Stosw 






15 


Mov 


AX,0804h 






StoSw 








no v 


SI,0C000h 






the reader 






20 


Mov 


AX , SCRATCHAREA 




mm 

Mov 


DS,AX 






caii 


CReaderCom 






MOV 


SI, 0003 




25 


response string 








Lodsb 








Jill LI. 

cmp 


AL,90h 






ue 


CodeOK 






LOuSO 






30 


Cmp 


AL,40h 














ue 


CardLock 






MOV 


DX, OClAh 




35 


MOV 


SI , offset 


BadPass 




call 


StrScr 






Jmp 


PwdLoop 






CardLock Lafcel 


Near 






MOV 


DX, OAlAh 




40 


Mov 


SI, offset 


Erase 




Call 


StrScr 






MOV 


DX,0ClAh 






Mov 


SI, offset Erase 




• Call 


StrScr 




45 


Mov 


DX,0B20h 




Mov 


SI, off set 


CdLck 




Call 


StrScr 






Mov 


DX,0ClAh 






Mov 


SI, off set 


CdLck2 



; Fill-in rest of 



/Present the code to 



;Look at the card 

;90h = code ok 

; 9 84 Oh = card locked 



;Give it another try 
;Card is locked... 



; Inform user 
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LockLoop 

loop 

CodeOK 
OK... 



10 



15 



20 GetPwd 



Call StrScr 

Mov SI f offset PowerOff 

Call CReaderCom 

Label Near 

Jmp LockLoop 



Label Near 



Mov 

Mov 

Call 

Mov 

Mov 

Call 

Pop 
Pop 
Pop 
Pop 
Ret 
Endp 



DX,0ClAh 

SI , offset Erase 

StrScr 

DX,0ClAh 

SI , offset Corrct 

StrScr 

DI 
DS 
CX 
AX 



;Hang in infinite 



; Presentation was 



; Inform user 



/Cleanup and return 



;Load partition boot record from card 



25 



30 



ReadPBR 



PBR file 



Proc 
Push 

Mov 
call 



Mov 
at 7000:C000 

Mov 
Mov 

35 bytes 

Stosw 

MOV 

Stosw 

Xor 

40 Stosw 
Mov 
Stosb 



45 bytes read 



RFLoop 



Xor 

Mov 
Label 



Near 
DS 

SI , offset SelPbrFl 

CReaderCom 

AX,0C000h 

DI,AX 
AX,0DB06h 

AX, OB200h 
AX, AX 
AL,34h 

DX,DX 

BH,01h 
Near 



; Select the 

;Form command 
; Store command 



;lnit no. 
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Mov 


AX,0C004h 






Mov 


DI,AX 






Hov 


AX,DX 






Mov 


CL,04h 


5 




Div 


CL 






Stosb 








Cmp 


BH, OAh 






Jne 


SendRdCmd 






Inc 


DI 


10 




Mov 


AL,2Ch 






Stosb 






SendRdCmd 


Label 


Near 






Mov 


SI,0C000h 






Mov 


AX , SCRATCHAREA 


15 




Mov 


DS,AX 






Call 


CReaderCom 






Push 


ES 






Xor 


AX, AX 






Mov 


ES,AX 


20 


segment 0000 








Mov 


SI, 0003 




bytes 










Mov 


AX,PBRAddress 






Add 


AX,DX 


25 




Mov 


DI,AX 






Add 


DX,0034h 






Mov 


CX,001Ah 






Cmp 


BH,0Ah 






Jne 


DoCopy 


o u 




Mov 


ex, oo ion 




DoCopy 


Label 


Near 






Repz 








Movsw 






a time 






•a K 




Pop 


ES 






Inc 


BH 






Cmp 


BH, OBh 






Jne 


RFLoop 






Pop 


DS 


40 




Ret 






ReadPBR 


Endp 






; Check integrity of 10. SYS 


45 


ChklO 


Proc 


Near 






Mov 


DX,0C2Ah 






Call 


CurPos 



destination 
;Skip header 



;Copy word at 



; Display filename 



Mov 



SI f offset Filel 
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Call 


StrScr 








Push 


BX 






simulation 


Mov 


BX f 0004h 


; Simcle delav for 








5 




Call 


Delay 








Pop 


BX 








Ret 








ChklO 


Endp 






10 


; Check integrity of MSDOS.SYS 






ChkMSDOS 


Proc 


Near 






filename 


Mov 


DX, 0C2Ah 


; Erase previous 


15 










Mov 


SI, offset SErase 








Call 


StrScr 








Mov 


DX,0C2Ah 


/Display filename 






Mov 


SI, offset File2 


20 




Call 


StrScr 








Push 


BX 






simulation 


Mov 


BX, 0004h 


; Simple delay for 








25 




Call 


Delay 






Pop 


BX 








Ret 








ChkMSDOS 


Endp 








; Check integrity of C0MMAND.COM 




30 










ChkCMD 


Proc 


Near 






filename 


Mov 


DX,0C2Ah 


; Erase previous 








35 




Mov 


SI, offset SErase 








Call 


StrScr 








Mov 


DX,0C2Ah 


; Display filename 






MOV 


SI, off set File3 






Call 


StrScr 




40 




Push 


BX 






simulation 


Mov 


BX,0004h 


/Simple delay for 












Call 


Delay 








Pop 


BX 




45 














Ret 








ChkCMD 


Endp 
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Check integrity of CONFIG.SYS 



ChkCFGSYS Proc 

5 

Mov 

filename 

Mov 
Call 

10 Mov 
Mov 
Call 
Push 
Mov 

15 simulation 

Call 
Pop 

Ret 

20 ChkCFGSYS Endp 



25 



30 



35 



40 



SendByte Proc 
45 Push 
Mov 
Push 
Push 



Near 

DX,0C2Ah 

SI, off set SErase 

StrScr 

DX,0C2Ah 

SI, offset File4 

StrScr 

BX 

BX,0004h 

Delay 
BX 



Near 
BP 

BP,SP 

AX 

DX 



; Erase previous 



; Display filename 



; Simple delay for 



Busy wait: 

- duration passed in BX 



Delay Proc Near 

Push BX 

Push CX 
DLoopO Label Near 

Mov CX,0000 
DLoopl Label Near 

Inc CX 

Cmp CX, OFFFFh 
Jne DLoopl 
Dec BX 
Jnz DLoopO 
Pop CX 
Pop BX 
Ret 
Delay Endp 



Transmit byte to COMl: 

- byte passed on stack 
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SendOly 
overrun 



10 



15 



20 SendByte 



Mov 
Label 

Inc 
Cmp 
Jnz 

Mov 

Mov 
Out 

Mov 
Mov 
Out 

Pop 
Pop 
Pop 
Ret 
Endp 



DX,0000 

Near ; Delay to prevent 

DX 

DX,00FFh 
SendDly 

DX,COMi_CTL_REG /Indicate send 

AL, OBh 
DX,AL 

DX,C0M1_DATA_REG ; Output byte to port 
AL,byte ptr [BP+4] 
DX, AL 



DX 
AX 
BP 



Transmit ASCII representation of byte to COMl: 
- byte passed on stack 



25 


ASendByte 


Proc 


Near 








Push 


BP 








Mov 


BP,SP 








Push 


AX 








Push 


DX 




30 




Push 


CX 








Mov 


AL,byte ptr [BP+4] 


;Get byte 






Mov 


AH, 00 








Mov 


CL,04h 








Shr 


AX,CL 


;Arith shift right 


35 




Cmp 


AX,0Ah 


; Result > 10 




(A..F) ? 












Jge 


HAlpha 


;Yes, calc ASCII 




for letter 












Add 


AL,30h 


;No, calc ASCII 


40 


for number 












Jmp 


HSend 






HAlpha 


Label 


Near 








Add 


AL,37h 


;Calc ASCII for 




letter 








45 


Hsend 


Label 


Near 








Push 


AX 
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call 


senaByte 




calculated. 


oyxe 








Add 


SP, 02h 


5 




Mov 


AL,byte ptr [BP+4] 






And 


AX, OOOFh 




nibble 










Cmp 


AX, OAh 




(A. .F) ? 






10 




Jge 


LAlpha 




for letter 










Add 


AL f 30h 




for number 










Jmp 


LSend 


15 


LAlpha 


Label 


Near 






m j j 
Add 


AL, 37h 




letter 








Lsend 


Label 


Near 






Push. 


AX 


20 




Call 


SendByte 




calculated. 


cy te 








Add 


SP,02h 






Pop 


CX 


25 




Pop 


DX 






Pop 


AX 






Pop 


BP 






Ret 






ASendByte 


Endp 





;Send out 

;Mask out high 
; Result > 10 
;Yes, calc ASCII 
;No, calc ASCII 

;calc ASCII for 

;Send out 



30 



35 



Get byte from COM1: 

-byte returned in AL 



RcvByte 



ready 
GetByte 



40 



45 



Proc 
Push 

Mov 

Label 
In 
And 
Jz 

Mov 
In 

Pop 
Ret 
Endp 



Near 
DX 



DX,C0M1_STATJREG ;Wait for receive 

Near 
AL,DX 
AL,01h 
GetByte 



DX , C0K1_DATA_REG 
AL, DX 

DX 



?Get byte 



RcvByte 
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;Get byte from COMl: converting from ASCII representation 
to byte 

; -byte returned in AL 

; -ETX returns 01 in AH, 00 otherwise 



10 



15 



20 



ARcvByte 



port 



high nibble 



HNumCvt 



RcvLow 
25 in BL 

from port 
nibble 

30 



35 



LNumCvt 



Combine 



40 into byte 



RcvEtx 



45 RcvDone 



Proc 


VT oar 

fical 


Push 


BX 


Push 


cx 


Call 


RcvByte 


Cmp 


AL,ETX 


Je 


RcvEtx 


Cmp 


AL f 41h 


Jge 


itNumvjvx 


OUD 


ajj, j un 


Jmp 


RCVLOW 


Label 


Near 


Sub 


AL, 37h 


Label 


Near 


MOV 


RL, AJj 


Call 


RcvByte 


Cmp 


AL, 41h 


Jge 


T Mi ^Trt i f 


Sub 


AL,30h 


Jmp 


Combine 




wear 


OUJJ 




T a Hoi 


n car 


Mov 


CL,04 


Shi 


BL,CL 


Or 


AL, BL 


Mov 


AH, 00 


Jmp 


RcvDone 


Label 


Near 


Mov 


AH, 01 


Label 


Near 


Pop 


CX 


Pop 


BX 


Ret 





;Get a byte from 
;Is it ETX? 

;Not ETX, convert to 



; Store high nibble 
;Get another byte 
; Convert to low 



; Combine h/1 nibbles 



;ETX, set AH = 1 
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ARcvByte Endp 



rSend NAK to reader/writer (request retransmission) 
5 SendNAK 



10 



15 



20 



25 



byte 



30 SendNAK 



Proc 
Push 


Near 
AX 




Mov 
Push 
Call 
Add 


AL, NAK 
AX 

SP,02h 


/Transmit NAK 


Mov 
Push 

tall 

Add 


AL,00 
AX 

jfc Con/4 Dtr4* a 

SP,02h 


; Command length is 


Mov 


AL, NAK 


;CRC is just NAK 


Push 
Call 
Add 


AX 

ASendByte 
SP,02h 




Mov 
Push 
Call 
Add 


AX,ETX 
AX 

SendByte 
SP,02h 


; Transmit ETX 


Pop 
Ret 
Endp 


AX 





Send command to reader /writer 

-check response for NAK and retransmit if 
necessary 

35 ; -pointer to string passed in DS:SI 

• r— _ 

f 

Near 
AX 
BX 
CX 
DX 



CReaderCom Proc 
Push 
Push 

40 Push 
Push 



CommandLoop Label Near 

Push DS 

Push SI 

45 call Reader Com 

command 



rSend reader /writer 
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Call 


CGetResp 


;Get reader /writer 




response 












Push 


ES 








Pop 


DS 




5 




Mov 


SI, 0000 








Lodsb 




;Look at first byte 




of response 










cmp 


AL,NAK 


;NAK? message not 




received properly 






10 




Jne 


RecvOK 


;Not NAK, message 




recieved 


OK 








Pop 


SI 








Pop 


DS 








Jmp 


CommandLoop 


;Try again 


15 


RecvOK 


Label 


Near 








Pop 


SI 








Pop 


DS 








Pop 


DX 








Pop 


CX 




20 




Pop 


BX 








Pop 


AX 








Ret 








CReaderCom Endp 






25 


;Send command to reader/writer 








-pointer to string passed in DS:SI 




ReaderCom Proc 


Near 








Mov 


AL, ACK 


; Transmit ACK 


30 




Mov 


BL, AL 


; Store for CRC 






Push 


AX 








Call 


ASendByte 








Add 


SP,02h 




35 




Lodsb 




;Load command length 






Xor 


BL, AL 


; Compute CRC 






Push 


AX 








Call 


AsendByte 


; Transmit command 




length 








40 




Add 


SP,02h" 








Mov 


CL,AL 


;Loop on command 




length 










Mov 


DL, 00 




45 


ComLoop 


Label 


Near 








Lodsb 




;Get next command 




byte 












Xor 


BL,AL 


; Compute CRC 
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byte 



10 CRC 



15 



Push 
Call 

Add 
Inc 
Cmp 
Jnz 

Push 

Call 
Add 

Mov 
Push 
Call 
Add 



AX 

ASendByte 

SP,02h 
DL 

DL,CL 
ComLoop 

BX 

ASendByte 
SP,02h 

AL,ETX 
AX 

SendByte 
SP,02h 



/Transmit command 



/Transmit computed 



/Transmit ETX 



Ret 

20 ReaderCom Endp 



25 



Get response from reader /writer 

- checks response CRC and requests 
retransmission if necessary 



CGetResp Proc 



RespLoop Label 
Mov 

destination ptr 
30 call 
string 

Cmp 
Jz 

finished 
35 call 
request retrans 
Jmp 

RespDone Label 
Ret 

40 CGetResp Endp 



Near 

Near 
Di f oooo 

GetResp 

AL,00 
RespDone 

SendNAK 

RespLoop 

Near 



/Initialize 

/Get the response 

/No error, we're 
/Error in response, 



Get a response string from reader /writer 

•response string stored starting at ES:DI 



45 GetResp Proc Near 
CharLoop Label Near 
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10 response 



Mov 

Call 

Stosb 

Xor 

Cmp 

Jnz 

Xor 
Dec 

Dec 

Lodsb 

Xor 



15 Cmp 
calculated CRC 
Jz 
Mov 

Ret 



error 

20 

RespOK 
error 

25 GetResp 



Label 
Mov 

Ret 
Endp 



BL, 00 
ARcvByte 

BL, AL 
AH, 01 
CharLoop 

BL,ETX 
Dl 

DI 

BL, AL 

AL,BL 

RespOK 
AL,01 



Near 
AL/00 



; Initialize for CRC 
;Recieve byte 

; Calculate CRC 
/Repeat until ETX 



; Remove ETX from CRC 
;Get CRC from 



/Remove CRC from CRC 
/Compare with 

/Return AL=01 if 



/Return AL=00 if no 



Display Contents of AX Register 



30 



35 



40 



/Save registers 



DispStat Proc Near 
Push CX 
Push BX 

Mov CX,0004h /Shift by one nibble 
Mov BX,AX /Save AX in BX 

Mov AL, AH 
Shr AL, CL 
Call DispNibble 



Mov AX,BX 
Mov AL, AH 
Call DispNibble 

Mov AX,BX 
Shr AL, CL 
Call DispNibble 

MOV AX,BX 
call DispNibble 



/Reset AX 



/Reset AX 



/Reset AX 
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5 DispStat 



Mov AX,BX 
Pop BX 
Pop CX 
Eet 
Endp 



; Reset AX 



Display character and advance cursor 

-character to be displayed is passed in AL 



10 DisplayChar 

15 should go away) 
0 



20 



count 



25 DisplayChar 



Proc 


Near 


Push 


AX 


Push 


BX 


Push 


CX 


Mov 


AH,0eh 


> 

Mov 


BH,00h 


Mov 


CX,01 


Int 


lOh 


Pop 


CX 


Pop 


BX 


Pop 


AX 


Ret 




Endp 





;Save contents of AX 
/Save contents of BX 
;Save character count 
; Display X's this 

; Select video page 



;Echo character 
; Restore CX to character 



/Restore BX 
; Restore AX 



Display nibble - character to be displayed is 
passed in the lower nibble of AL 



30 DispNibble 



35 



40 



letter 



45 DispNibble 



Proc Near 

Push AX 
And AL,0Fh 
Cmp AL,0Ah 
Jge letter 
Add AL,'0' 

Call DisplayChar 

Pop AX /Restore AX 

Ret 

Label Near 
Sub AL, OAh 
Add AL,'A' 

Call DisplayChar 

Pop AX /Restore AX 

Ret 

Endp 



;Save contents of AX 
/Mask AL 

/Display A-F not digit 



Send string to screen 

-pointer to string passed in DS:SI 
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screen passed in DX (row, col) 





strscr 


Proc 


Near 








Push 


AX 




5 




Push 


BX 








Push 


CX 






service 9 


Mov 


AH, 09 


Tlnterruot 10 














Mov 


BH,00 


; Video uaae 0 


10 




Lodsb 








Mov 


BL, AL 


;Load attribir 




byte 












Mov 


CX,0001 


rOnlv disDlav 




one of each char 




15 


Scrloop 


Label 


Near 








Call 


CurPos 


;Move cursor 






Lodsb 










Or 


AL, AL 


;0ur end of 




string byte? 








20 




Jz 


ScrDone 


iTf so. we're 




done . . . 












Int 


lOh 


• Othefwi se 




display character 










Inc 


DX 


; Increment 


25 


cursor position 












Jmp 


ScrLoop 


/Repeat with 




next character 








ScrDone 


Label 


Near 




30 




Pop 


CX 








Pop 


BX 








Pop 


AX 








Ret 








StrScr 


Endp 







35 



40 



45 



Draw box frame for dialog 
DrawBox 



Proc 


Near 


Mov 


DX,0517h 


Call 


CurPos 


Mov 


AH, 09 


Mov 


BH,00 


Mov 


BL,07 


Mov 


CX,0001 


Mov 


AL,0C9h 


Int 


lOh 


Mov 


DX,0518h 



; Service 9 

; Primary video page 

/Character attribute 

/Display only one 
/Upper left corner 



/Top bar 
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10 



15 



20 



25 



30 LSide 



35 



RSide 



40 



DrawBox 



Call 


CurPos 


Mr%v 


AL . OCDh 


Mov 


CX, OOlFh 




lOh 


MOV 


DX,0537h 


Call 


CurPos 


MOV 


AL,0BBh 


Mov 


CX,0001 


Int 


lOh 


Mov 


DX, 0E17h 


wall 


nirPos 


MOV 


AL,0C8h 


Int 


lOh 


Mov 


DX, 0E18h 


Call 


CurPos 


JaOV 


AT. OCDh 


Mov 


CX, OOlFh 


Int 


lOh 


Mov 


DX,0E37h 


Call 


CurPos 


Mov 


AL , OBCh 


Mov 


CX,0001 


int 


lOh 


Mov 


DX,0617h 


Mov 


AL, OBAh 


Label 


Near 


call 


CurPos 


Int 


lOh 


Add 


DX, OlOOh 


Cmp 


DX,0E17h 


Jne 


LSide 


Mov 


DX f 063/tl 


Label 


Near 


Call 


CurPos 


Int 


lOh 


Add 


DX, OlOOh 


Cmp 


DX,0E37h 


Jne 


RSide 


Ret 




Endp 





; Upper right corner 



; Lower left corner 



; Bottom bar 



; Lower right corner 



;Left side 



/Right side 



45 



Clear screen 
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Clrscr 



10 spaces 



15 



again 



20 



25 ClrScr 



Proc 


Near 


Push 


AX 


Push 


BX 


Push 


CX 


Push 


DX 


Mov 


DX, OOOOh 


Call 


CurPos 


Mov 


AH,09h 


Mov 


CX, 0800h 


Mov 


AL,020h 


Mov 


BH,00h 


MOV 


BL,07h 


Int 


lOh 




DY 0000 


Call 


CurPos 


Pop 


DX 


Pop 


CX 


Pop 


BX 


Pop 


AX 


Ret 




Endp 





30 



35 



;Home cursor 
;Fill screen with 



;Home cursor yet 



Set cursor position 

-cursor row passed in DH 
-cursor column passed in DL 



CurPos 



service 2 



40 



CurPos 



Proc 


Near 


Push 


AX 


Push 


BX 


Mov 


AH, 02 


Mov 


BH,00 


Int 


lOh 


Pop 


BX 


Pop 


AX 


Ret 




Endp 





; Interrupt 10 
; Video page 0 



45 



Data area 

- Console messages 

- iso command strings 
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f 

; .Data 



; Console messages 





STitle 


DB 


OAh 


5 


;Char attribute 


(clr) 








DB 


'Boot Integrity Token System' 




/String 










DB 


OOh 




;End of string marker 




10 


SSTitle 


DB 


OAh 






DB 


'DOS-BITS Version 1' 






DB 


OOh 




InsrtCrd 


DB 


07h 






DB 


'Please insert card. . . ' 


15 




DB 


OOh 




SErase 


DB 


07h 






DB 


/ r 






DB 


OOh 




Erase 


DB 


07h 


20 




DB 








DB 


OOh 




PwdPnnpt 


DB 


07h 




DB 


'Password: ' 






DB 


OOh 


25 


BadPass 


DB 


07h 






DB 


'Incorrect. Please try again. ' 






DB 


OOh 




Corrct 


DB 


07h 






DB 


'Loading operating system. . . ' 


30 




DB 


OOh 




CdLck 


DB 


OFh 






DB 


'Card is locked!' 






DB 


OOh 




CdLck2 


DB 


OFh 


35 




DB 


'Please see Security Manager.' 






DB 


OOh 




KbdStat 


DB 


07h 






DB 


'Keyboard status: ' 






DB 


OOh 


40 


FileChk 


DB 


07h 






DB 


'Checking files: ' 






DB 


OOh 




Filel 


DB 


07h 






DB 


'10. SYS' 


45 




DB 


OOh 




File2 


DB 


07h 






DB 


'MSDOS.SYS' 






DB 


OOh 




File3 


DB 


07h 
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' COMMAND . COM ' 




nc 

UD 




r lie4 


UD 


07h 




DB 


'CONFIG.SYS' 




DB 


OOh 


BadFile 


DB 


07h 




DB 


'Missing or corrupted system 


L lie • 








DB 


OOh 


OKFile 


DB 


07h 




DB 


'Files OK. Booting...' 




DB 


OOh 


; Shared secret 


(card/PC) 


data 


SharSec 


DB 


OOh 



15 ; Reader and card command strings 



InitRdr 
StCrdTp 
RstCard 
PowerOn 
20 Power Off 
SelPbrFl 



DB 04h, 03h, OFh, ODOh, OAh 

DB 03h,02h # 02h,00h 

DB 04h, 03h, OFh, ODOh, OAh 

DB 04h, 6Eh, Olh, OOh, OOh 

DB 01h,4Dh 

DB 06h , ODBh , OOh , 0A2h , 02h , 7Eh , 08h 



;Operating system filenames 



SysFilel 
SysFile2 
25 SysFile3 



DB 
DB 
DB 



'10 SYS' 
'MSDOS SYS' 
'COMMAND COM' 



;End, data area 
Cseg Ends 
END 
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What is claimed is: 

1. A method for reducing the possibility of 
corruption of critical information required in the 
operation of a computer comprising: 

5 storing the critical information in a device, 

communicating authorization information between 
the device and the computer, and 

causing the device, in response to the 
authorization information, to enable the computer to read 
10 the critical information stored in the device. 

2. The method of claim 1 wherein the steps of 
communicating authorization information and enabling the 
computer to read comprise 

a user entering a password, and 
15 the device verifying the password. 

3. The method of claim 1 wherein the 
authorization information comprises biometric information 

about a user. 

4. The method of claim 1 further comprising 
20 storing a password in the device, 

in the device, comparing the stored password with 
an externally supplied password, and 

basing a determination of whether to enable the 
computer to read the stored critical information on the 
25 results of the step of comparing the passwords. 

5. The method of claim 1 wherein the device 
comprises a microprocessor and a memory. 

6. The method of claim 5 wherein the device 
comprises a pocket-sized card containing the 

30 microprocessor and the memory. 

7. The method of claim 1 wherein said critical 
information comprises boot-sector information used in 
starting the computer. 
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8. The method of claim 1 wherein said critical 
information comprises executable code. 

9. The method of claim 1 wherein said critical 
information comprises system data or user data. 

5 10. The method of claim 1 further comprising 

the computer booting itself from the critical 
information read from the device. 

11. The method of claim 1 wherein the computer 
booting itself comprises executing modified boot code in 

10 place of normal boot code. 

12. The method of claim 11 further comprising 
storing the modified boot code in the form of a BIOS 
extension. 

13. The method of claim 1 wherein the steps of 
15 communicating authorization information and enabling the 

computer to read, comprise 

the device passing to the computer, secret 
information shared with the computer, and 

the computer validating the shared secret 
20 information passed from the device. 

14. The method of claim 1 wherein the 
authorization information comprises file signatures for 
executable code. 

15. The method of claim 1 wherein the 
25 authorization information comprises a user's 

cryptographic key. 

16. The method of claim 13 wherein the shared 
secret information comprises a host access code. 

17. The method of claim 1 wherein the stored 

30 critical information includes file integrity information. 
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18. A method of booting a computer, comprising 
storing, in a device which is separate from the 
computer, boot information, user authorization 
information, and device authorization information in the 
5 form of a secret shared with the computer, 

providing a communication link between the device 

and the computer, 

receiving possibly valid authorization information 

from a user, 

10 in the device, checking the possibly valid 

authorization information against the stored user 
authorization information to determine validity, 

if the password is determined to be valid, passing 
the boot information and the shared secret information 
15 from the device to the computer, 

in the computer, checking the validity of the 
shared secret information, and 

if the shared secret information is valid, using 
the boot information in booting the computer. 

19. A method for initializing a device for use in 
reducing the possibility of corruption of critical 
information required in the operation of a computer 
comprising: 

storing the critical information in memory on the 

25 device, 

storing authorization information in memory on the 
device, and 

configuring a microprocessor in the device to 
release the critical information to the computer only 
30 after completing an authorization routine based on the 
authorization information. 

20. The method of claim 19 wherein said critical 
information comprises boot information. 



20 
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21. The method of claim 20 further comprising 
storing file integrity information in the memory of the 
device. 

22. The method of claim 20 further comprising 
5 storing system or user data in the device. 

23. The method of claim 20 further comprising 
storing executables in the memory of the device. 

24. A portable intelligent token for use in 
effecting a secure startup of a host computer comprising 

10 a housing, 

a memory within said housing, the memory 
containing information needed for startup of the host 

computer , and 

a channel for allowing the memory to be accessed 

15 externally of the housing. 

25. The token of claim 24 wherein said memory 
also contains a password for authorization, said token 

further comprising 

a processor for comparing the stored password with 

20 externally supplied passwords. 

26. The token of claim 24 wherein the memory 
stores information with respect to multiple host 
computers . 

27. The token of claim 24 wherein said housing 
25 comprises a pocket-sized card. 
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